Справочный центр ALD Pro 3.2.1
Управление системными учетными записями¶
Введение¶
Инструкция предназначена для предоставления информации о безопасном и корректном механизме управления системными учетными записями, используемыми для работы ALD Pro.
Термины и определения¶
Контроллер домена (КД) - сервер, который контролирует определенную область компьютерной сети, а также управляет доступом к различным ресурсам внутри этой области.
Служба каталога - средство иерархического представления ресурсов и информации об этих ресурсах.
Lightweight Directory Access Protocol (LDAP) - протокол прикладного уровня для доступа к службе каталогов, разработанный как облегчённый вариант протокола DAP. LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции аутентификации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей.
Free Identity Policy and Audit (FreeIPA) - открытое программное обеспечение, специализированная служба каталогов, предназначенная для создания в ОС Linux среды, позволяющей централизованно управлять аутентификацией пользователей, устанавливать политики доступа и аудита. Функционал FreeIPA подобен Active Directory, используемому в Windows.
389 Directory Server (389 DS) - служба каталогов уровня предприятия с открытым исходным кодом, предназначенная для централизованного управления доступом к ресурсам на множестве сетевых серверов.
Системная учетная запись (Системная УЗ) - под системными учетными записями понимаются записи службы каталога, находящиеся в контейнере
cn=sysaccounts,cn=ipa,dc={domain_component}, а также специальные учетные записи PostgreSQL, RabbitMQ, Zabbix, Grafana, используемые ALD Pro для выполнения различных действий, не связанных с действиями пользователей системы. Эти учетные записи не предназначены для обычных пользователей и обеспечивают функционирование различных сервисов и ролей внутри инфраструктуры, поддерживая безопасность и доступ в системе на уровне домена.Secure Shell (SSH) - сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений.
Samba - пакет программ, которые позволяют обращаться к сетевым дискам и принтерам на различных операционных системах по протоколу SMB/CIFS.
Domain Name System (DNS) - система доменных имён — это иерархическая децентрализованная система именования для ресурсов, подключённых к глобальной сети, которая ведёт список доменных имён вместе с их числовыми IP-адресами или местонахождениями.
Kerberos - сетевой протокол аутентификации, который предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними. Kerberos выполняет аутентификацию в качестве службы аутентификации доверенной третьей стороны, используя криптографический ключ. Kerberos построен на криптографии симметричных ключей и требует наличия центра распределения ключей. Расширения Kerberos могут обеспечить использование криптографии с открытым ключом на определённых этапах аутентификации.
Internet Protocol (IP) - маршрутизируемый протокол сетевого уровня стека TCP/IP.
Transmission Control Protocol (TCP) - протокол управления передачей - протокол сети интернет, который позволяет двум хостам создать соединение и обмениваться потоками данных. TCP гарантирует доставку данных и пакетов в том же порядке, в котором они были отправлены.
IP-адрес - уникальный числовой идентификатор устройства в компьютерной сети, работающей по протоколу IP.
Аccess control instruction (ACI) - инструкция управления доступом, которая определяет, кто или что может получать доступ к объекту (программе, процессу или файлу), и какие именно операции разрешено или запрещено выполнять субъекту (пользователю, группе пользователей).
Общий алгоритм смены учетных данных для системных учетных записей в 389 DS¶
Общее описание¶
В ALD Pro используются системные учетные записи для различных целей, связанных с управлением внутренними сервисами, выполнением различных служебных операций, управлением инфраструктурой безопасности и аутентификацией. Эти учетные записи хранятся в контейнере cn=sysaccounts,cn=etc базы данных LDAP, которая управляется с помощью одного из компонентов FreeIPA — 389 Directory Server (389 DS). Этот контейнер является частью структуры службы каталога, и его основная роль заключается в хранении специальных учетных записей, которые необходимы для работы сервисов и выполнения административных задач.
Смена учетных данных для системных учетных записей должна проводиться очень осторожно, поскольку эти учетные записи используются как самой службой FreeIPA, так и внешними приложениями или сервисами для доступа к базе данных LDAP или другим сервисам в инфраструктуре. Это важно, поскольку нужно убедиться, что после учетных данных внешние приложения продолжат корректно работать.
Идентификация учетных записей и их использования¶
Перед операциями над системными УЗ необходимо определить, какие внешние приложения или сервисы используют эти системные учетные записи. Это могут быть:
различные сервисы из состава ALD Pro;
сервис репликации между серверами FreeIPA;
система для управления сертификатами;
программы для интеграции с Active Directory;
службы аутентификации через LDAP или Kerberos;
другие сервисы, которые подключаются под системными учетными записями, используют LDAP для своих нужд и функционируют в текущей инфраструктуре.
Подготовка к смене учетных данных для системных учетных записей¶
Перед сменой учетных данных необходимо выполнить следующие действия:
убедиться, что существуют рабочие резервные копии конфигураций всех внешних приложений, которые используют эти учетные записи;
оповестить ответственных за приложения или службы, использующие эти учетные записи, о предстоящей смене учетных данных, чтобы была возможность подготовиться к обновлению в своих конфигурациях (для сервисов и приложений, которые используют службу каталогов, но не входят в комплект поставки ALD Pro);
проверить настройки конфигурации в самих внешних приложениях, чтобы удостовериться, что они могут работать с новыми учетными данными.
Обновление конфигурации внешних приложений¶
После того как учетные данные для системных учетных записей в службе каталога были изменены, необходимо обновить их в конфигурациях внешних приложений, которые используют эти учетные записи для подключения к LDAP или другим сервисам.
В зависимости от того, какие внешние сервисы используют системные учетные записи, нужно будет обновить конфигурацию подключения в каждом приложении.
Для сервисов, использующих LDAP, таких как приложения, которые подключаются к 389 DS из состава FreeIPA для аутентификации, обновить файл конфигурации LDAP, где прописаны учетные данные (или тот контейнер, откуда эти сервисы получают данные для аутентификации в LDAP). Внести изменения в конфигурационные файлы (контейнеры) каждого такого сервиса.
Для Kerberos: Если системные учетные записи используются для аутентификации через Kerberos, обновить принципал Kerberos. Например:
kadmin.local -q "changepw some_kerberos_service"Если это сервисный принципал, то, возможно, потребуется перезапуск служб, использующих Kerberos.
Если внешнее приложение использует учетную запись для других сервисов, например, для генерации сертификатов или управления политиками, необходимо убедиться, что данные обновлены в конфигурации этих сервисов. Например:
для
ipa-certmaster: обновить конфигурационные файлы и убедиться, что процесс управления сертификатами будет продолжать работать;для
ipa-otpd: проверить, что изменения не повлияют на систему One-Time Password.
Перезапуск служб и тестирование работоспособности¶
После изменения учетных данных и обновления конфигураций приложений необходимо:
Перезапустить все сервисы, которые используют эти учетные записи. Это может включать:
FreeIPA (IPA сервисы);
389 DS (служба LDAP);
службы репликации;
сервисы, использующие Kerberos или Sudo;
другие связанные сервисы и приложения.
Провести тестирование, чтобы убедиться, что все сервисы, использующие эти учетные записи, продолжают функционировать правильно. Это можно сделать, проверив подключение к LDAP, а также тестируя репликацию, аутентификацию пользователей и доступ к другим сервисам.
Мониторинг дальнейшей работы сервисов, использующих в своей работе системные учетные записи¶
После смены учетных данных и обновления конфигураций важно мониторить систему, чтобы убедиться, что нет сбоев или ошибок, связанных с неправильными учетными данными. Рекомендуется протестировать изменения в контролируемой среде перед их внедрением в рабочую инфраструктуру. Кроме того, необходимо иметь четкий план восстановления, чтобы оперативно устранить возможные ошибки в случае возникновения непредвиденных обстоятельств.
Управление системными учетными записями, используемыми ALD Pro, при работе с одной версией продукта¶
Общее описание¶
Системные учетные записи создаются автоматически при установке и настройке ALD Pro (также при настройке интеграции с RuPost) и не предназначены для обычного использования конечными пользователями.
Доступ системных учетных записей из ветки cn=sysaccounts,cn=etc к данным службы каталога настраивается с помощью ACI и механизма ролей/привилегий/разрешений ALD Pro, которые определяют, какие операции могут быть выполнены на уровне данных LDAP. Предустановленные в ALD Pro системные учетные записи настроены с такими ограничениями, которые обеспечивают безопасность и контролируют доступ к критически важным данным, обеспечивая правильную работу тех прикладных сервисов, которые подключаются к службе каталога под данными учетными записями.
Смена учетных данных для системных учетных записей должна проводиться крайне осторожно, поскольку эти учетные записи используются внешними приложениями или сервисами для доступа к базе данных LDAP или другим сервисам в инфраструктуре ALD Pro. Важно убедиться, что после смены учетных данных все компоненты ALD Pro и другие внешние приложения инфраструктуры продолжат корректно работать. Смена учетных данных для системных учетных записей, которые не хранятся в базе данных службы каталога, а используются для работы с другими внешними относительно ALD Pro продуктами (например, Zabbix, PostgreSQL), описана ниже.
Проверка репликации данных между экземплярами 389 Directory Server¶
Перед началом работы с системными учетными записями важно убедиться, что репликация данных работает корректно. Проверить состояние репликации с помощью следующих команд с выводом информации о состоянии в формате JSON:
dsconf -j <INSTANCE> replication status --suffix <SUFFIX>
где <INSTANCE> - имя экземпляра службы каталога, а <SUFFIX> - доменный суффикс. Для получения списка <INSTANCE> можно воспользоваться командой dsctl -l.
Например:
dsconf -j EXAMPLE-RU replication status --suffix dc=example,dc=ru
Если в результате команды выдается ответ в формате JSON со следующей парой ключ-значение:
{
"desc": "No object exists given the filter criteria..."
}
это означает, что репликация в данный момент не найдена или некорректно заданы условия для команды. Необходимо убедиться в том, что в портале управления ALD Pro в подразделе Управление доменом → Сайты и службы, на вкладке Соглашения о репликации присутствуют данные о репликации.
Проверить состояние репликации между серверами можно с помощью утилиты ds-replcheck:
ds-replcheck online -D "cn=Directory Manager" -m ldap://dc-1.ald.company.local:389 -r ldap://dc-2.ald.company.local:389 -b dc=ald,dc=company,dc=local
В случае отсутствия команды dsconf на конкретном КД, следует установить ее следующей командой:
sudo apt-get install python3-lib389
Управление системными учетными записями¶
К системным учетным записям, используемым для обеспечения корректной и бесперебойной работы ALD Pro, относятся следующие записи (по умолчанию при установке продукта находятся в файлах конфигурации ALD Pro):
Системная УЗ |
Описание |
Подсистема |
Компонент |
|---|---|---|---|
uid=aldpro_srv_zabbix,cn=sysaccounts,cn=etc,$SUFFIX
|
Системная учетная запись для обеспечения аутентификации с системой мониторинга Zabbix. С версии 3.1.0 не используется сервисами ALD Pro. |
КД |
389 DS |
uid=commonenv,cn=sysaccounts,cn=etc,$SUFFIX
|
Системная учетная запись для чтения переменных окружения, используемых различными сервисами. С версии 3.1.0 не используется сервисами ALD Pro. |
КД |
389 DS |
uid=orgunitsservice,cn=sysaccounts,cn=etc,$SUFFIX
|
Системная учетная запись управления организационными подразделениями. |
КД |
389 DS |
uid=roleservice,cn=sysaccounts,cn=etc,$SUFFIX
|
Системная учетная запись для управления ролями и правами доступа. |
КД |
389 DS |
uid=saltstackservice,cn=sysaccounts,cn=etc,$SUFFIX
|
Системная учетная запись системы управления конфигурациями SaltStack, используемая для автоматизированного развертывания и настройки компонентов или объектов каталога. |
КД |
389 DS |
uid=simple_repo,cn=sysaccounts,cn=etc,$SUFFIX
|
Системная учетная запись для подсистемы репозиториев. Используется для доступа к ipaSshPubKey. |
КД |
389 DS |
uid=syncer/dc01.example.ru@EXAMPLE.RU,cn=sysaccounts,cn=etc,$SUFFIX
|
Системная учетная запись, обеспечивающая синхронизацию данных MS AD с указанным сервером. В рамках текущей архитектуры модуль синхронизации функционирует на первом контроллере домена, что обусловливает корректность возможного отсутствия системных учетных записей Syncer на репликах КД. |
КД |
389 DS |
uid=trustsservice,cn=sysaccounts,cn=etc,$SUFFIX
|
Системная учетная запись сервиса управления доверительными отношениями между доменами. |
КД |
389 DS |
async_db
|
Системная учетная запись, предназначенная для асинхронных операций с базой данных (фоновые задачи, обработка очередей или отложенные транзакции). Обеспечивает выполнение запросов без блокировки основного потока обработки данных. |
КД |
PostgreSQL |
core_db
|
Системная учетная запись портала управления ALD Pro, используемая системными процессами для доступа к базе данных. |
КД |
PostgreSQL |
syncer_db
|
Системная учетная запись, ответственная за синхронизацию данных между PostgreSQL и другими системами (например, LDAP-каталогом). Обеспечивает поддержание консистентности данных. |
КД |
PostgreSQL |
repo_db
|
Системная учетная запись для управления данными в репозиториях. |
Репозиториии ПО |
PostgreSQL |
osinstall_db
|
Системная учетная запись сервиса сетевой установки ОС, ответственная за хранение и обработку конфигураций PXE. |
Установка ОС по сети |
PostgreSQL |
zabbix
|
Системная учетная запись службы мониторинга Zabbix, предназначенная для сбора метрик производительности, хранения исторических данных и обработки триггеров. С версии 3.1.0 не использует пароль, подключение ведется по сокету. |
Мониторинг |
PostgreSQL |
async_rabbitmq
|
Системная учетная запись для асинхронных операций взаимодействия портала управления ALD Pro. |
КД |
RabbitMQ |
core_rabbitmq
|
Системная учетная запись для основных операций портала управления ALD Pro брокера сообщений. |
КД |
RabbitMQ |
repo_rabbitmq
|
Системная учетная запись для управления сообщениями в системе репозиториев. |
Репозиториии ПО |
RabbitMQ |
osinstall_rabbitmq
|
Системная учетная запись для сетевой установки ОС. |
Установка ОС по сети |
RabbitMQ |
monitoring
|
Системная учетная запись для отображения данных мониторинга в портале управления. |
Мониторинг |
Zabbix |
zabbix_api
|
Системная учетная запись для загрузки шаблонов и интеграции с Grafana. |
Мониторинг |
Zabbix |
admin (Grafana)
|
Системная учетная запись для загрузки дашбордов и настройки интеграции с Zabbix. В указанных операциях для корректной настройки используется системная учетная запись Grafana, предопределенная в конфигурации |
Мониторинг |
Grafana |
Также стоит учитывать, что при обновлении с младших версий, в списке системных УЗ будут присутствовать устаревшие системные записи для обеспечения обратной совместимости, в том числе в назначенных aci и атрибутах member необходимых ролей/привилегий/разрешений, которые возможно заблокировать или удалить после корректного обновления всех подсистем.
Важно
Системные УЗ уникальны для каждой подсистемы и КД, поэтому имя УЗ формируется по шаблону <system_account_name>_<api/db/rabbitmq>_<short_hostname>, например, saltstackservice_dc01 или core_db_dc01.
Управление системными учетными записями 389 Directory Server, используемыми для работы ALD Pro¶
Управление системными учетными записями 389 DS¶
Системные учетные записи 389 Directory Server зачастую необходимы для интеграций со сторонними приложениями и службами, которые поддерживают LDAP-аутентификацию. Управление системными УЗ 389 DS производится встроенными командами администрирования LDAP-каталога, более подробную информацию о которых возможно найти в справочной документации LDAP/389 DS.
Процесс создания системной учетной записи предполагает использование утилиты ldapadd с аутентификацией под учетной записью администратора, имеющим соответствующие права на контейнер cn=sysaccounts. Необходимо сформировать LDIF-документ, содержащий атрибуты: objectClass (account, nsMemberOf (опционально, зависит от необходимости назначения роли для УЗ), simplesecurityobject, top), userPassword и uid. Пароль должен быть хешированным, однако на практике допускается использование открытого текста с последующим автоматическим хешированием сервером:
ldapadd -x -D "cn=Directory Manager" -W <<EOF
dn: uid=system_account,cn=sysaccounts,cn=etc,dc=example,dc=ru
objectClass: account
objectClass: nsMemberOf
objectClass: simplesecurityobject
objectClass: top
uid: system_account
userPassword: password_string
EOF
Для изменения атрибутов существующей системной учетной записи применяется утилита ldapmodify. Наиболее частые операции включают смену пароля, добавление членства в группах через механизм nsMemberOf. При смене пароля рекомендуется использовать метод замены (changetype: modify) с операцией replace:
ldapmodify -x -D "cn=Directory Manager" -W <<EOF
dn: uid=system_account,cn=sysaccounts,cn=etc,dc=example,dc=ru
changetype: modify
replace: userPassword
userPassword: password_string
EOF
Права доступа для системных учетных записей могут назначаться как через стандартные механизмы ролевого доступа, так и через прямые назначения ACI. Рекомендуется использовать подход с правами через роли и привилегии, так как назначение ACI на конкретную системную учетную запись в дальнейшем приведет к сложности поддержки согласованности и консистентности информации о контроле доступа.
Назначение ролей/привилегий/разрешений осуществляется через атрибут member:
ldapmodify -x -D "cn=Directory Manager" -W <<EOF
dn: cn=<role_name>,cn=roles,cn=accounts,dc=example,dc=ru
changetype: modify
replace: member
member: uid=<system_account>,cn=sysaccounts,cn=etc,dc=example,dc=ru
EOF
Прямое создание ACI для системной учетной записи требует добавления записей контроля доступа в точку привязки ACI. Например, для предоставления прав на чтение всех записей в определенном поддереве (cn=sysaccounts):
ldapmodify -x -D "cn=Directory Manager" -W <<EOF
dn: cn=sysaccounts,cn=etc,dc=example,dc=ru
changetype: modify
add: aci
aci: (targetattr="*")(version 3.0; acl "System Account Access"; allow (read, search, compare) userdn="ldap:///uid=system_account,cn=sysaccounts,cn=etc,dc=example,dc=ru";)
EOF
Удаление системных учетных записей выполняется с помощью утилиты ldapdelete. Перед удалением необходимо убедиться, что учетная запись не используется какими-либо службами или приложениями, а также проверить и удалить все связанные ACI:
ldapdelete -x -D "cn=Directory Manager" -W "uid=system_account,cn=sysaccounts,cn=etc,dc=example,dc=ru"
Полное удаление ACI записи применяется когда ACI существует исключительно для предоставления прав целевой системной учетной записи и не содержит других субъектов доступа:
ldapmodify -x -D "cn=Directory Manager" -W <<EOF
dn: cn=sysaccounts,cn=etc,dc=example,dc=ru
changetype: modify
delete: aci
aci: (targetattr="*")(version 3.0; acl "System Account Access";
allow (read, search, compare)
userdn="ldap:///uid=system_account,cn=sysaccounts,cn=etc,dc=example,dc=ru";)
EOF
Если системная учетная запись включена в группу, которая упомянута в ACI, необходимо изменить сам ACI, либо модифицировать состав группы:
ldapmodify -x -D "cn=Directory Manager" -W <<EOF
dn: cn=service_group,cn=groups,cn=accounts,dc=example,dc=ru
changetype: modify
delete: member
member: uid=system_account,cn=sysaccounts,cn=etc,dc=example,dc=ru
EOF
При возникновении проблем с аутентификацией системных учетных записей следует проверить:
корректность пароля;
наличие необходимых ACI для доступа к целевым ресурсам;
отсутствие конфликтующих правил доступа;
соответствие DN учетной записи в ACI и фактическому DN.
Для отладки возможно использовать утилиту ldapsearch и анализ журналов доступа Directory Server.
Переопределение системных УЗ 389 DS¶
В этом разделе описана замена учетных данных для всех системных учетных записей, расположенных в cn=sysaccounts,cn=etc,dc=example,dc=ru.
Важно
Изменение учетных данных для системной учетной записи в 389 DS приведет к прекращению работы всех сервисов, использующих данную учетную запись, до обновления их конфигураций с новыми данными и последующего перезапуска. В связи с этим после введения изменений из данного раздела, некоторые функции ALD Pro могут стать недоступны до корректировки в конфигурационных файлах продукта и перезапуска сервера Apache.
Примечание
При создании пароля для учетной записи можно использовать a-z, A-Z, 0-9.
Для того, чтобы выполнить замену системной УЗ необходимо создать аналогичную учетную запись:
Системная УЗ |
Создание УЗ для замены |
|---|---|
uid=orgunitsservice_*,cn=sysaccounts,cn=etc,$SUFFIX
|
Создать новую учетную запись, которая заменит неактуальную:
|
uid=orgunitsservice_*,cn=sysaccounts,cn=etc,$SUFFIX
|
Выдать права новой системной УЗ:
|
uid=roleservice_*,cn=sysaccounts,cn=etc,$SUFFIX
|
Создать новую учетную запись, которая заменит неактуальную:
|
uid=roleservice_*,cn=sysaccounts,cn=etc,$SUFFIX
|
Выдать права новой системной УЗ:
|
uid=saltstackservice_*,cn=sysaccounts,cn=etc,$SUFFIX
|
Создать новую учетную запись, которая заменит неактуальную:
|
uid=saltstackservice_*,cn=sysaccounts,cn=etc,$SUFFIX
|
Выдать права новой системной УЗ:
|
uid=trustsservice_*,cn=sysaccounts,cn=etc,$SUFFIX
|
Создать новую учетную запись, которая заменит неактуальную:
|
uid=trustsservice_*,cn=sysaccounts,cn=etc,$SUFFIX
|
Выдать права новой системной УЗ:
|
uid=syncer/dc01.example.ru@EXAMPLE.RU,cn=sysaccounts,cn=etc,$SUFFIX
|
Создать новую учетную запись, которая заменит неактуальную:
|
uid=syncer/dc01.example.ru@EXAMPLE.RU,cn=sysaccounts,cn=etc,$SUFFIX
|
Выдать права новой системной УЗ:
Актуализировать учетные данные для подключения к контроллеру ALD во вкладке: Модуль синхронизации / Настройки / Контроллеры домена ALD. |
uid=simple_*,cn=sysaccounts,cn=etc,$SUFFIX
|
Создать новую учетную запись, которая заменит неактуальную: ldapadd -x -D "cn=Directory Manager" -W <<EOF
dn: uid=<new_simple_repo>,cn=sysaccounts,cn=etc,dc=example,dc=ru
objectClass: account
objectClass: nsMemberOf
objectClass: simplesecurityobject
objectClass: top
userPassword: {newSimpleRepoPassword}
EOF
|
uid=simple_*,cn=sysaccounts,cn=etc,$SUFFIX
|
Выдать права новой системной УЗ:
|
На данном шаге, при обновлении только пароля существующей системной УЗ, необходимо выполнить команду:
ldapmodify -x -D "cn=Directory Manager" -W <<EOF
dn: uid=<system_account>,cn=sysaccounts,cn=etc,dc=example,dc=ru
changetype: modify
replace: userPassword
userPassword: <newPassword>
EOF
При обновлении УЗ Syncer необходимо дополнительно актуализировать пароль для подключения к контроллеру ALD во вкладке: Модуль синхронизации / Настройки / Контроллеры домена ALD.
Далее необходимо преобразовать пароль для корректного хранения в файлах конфигурации.
Скачать публичный ключ:
aldpro-salt-call aldpro_subsystems.get_crt_pass_to_fs /tmp/test_cert.crt
где /tmp/test_cert.crt абсолютный путь до ключа.
Преобразовать пароль:
aldpro-salt-call aldpro_subsystems.password_encrypt '<PASSWORD>' public_cert_path=/tmp/test_cert.crt
Актуализировать учетные данные в ключах username и password записи обновляемого КД, в случае обновления simple_repo - на сервере репозиториев, DN: fqdn=<fqdn>,cn=computers,cn=accounts,dc=example,dc=ru в атрибуте aldproSubsystemVaultCredentials. Например, для roleservice файл конфигурации будет выглядеть следующим образом:
{
"passwords": {
"roleservice": {
"group": "roleservice",
"password": "roleserviceEncryptPassword",
"simple_bind": true,
"username": "new_roleservice"
}
}
}
Обновить значения ключей username и password в /etc/aldpro-salt/stack/encrypted_passwords.yml на КД, а в случае обновления simple_repo - на сервере репозиториев. Например, для roleservice файл конфигурации будет выглядеть следующим образом:
roleservice:
group: roleservice
password: roleserviceEncryptPassword
simple_bind: true
username: new_roleservice
Заменить учетные данные в файлах конфигурации:
Системная УЗ |
Подсистема |
Файл конфигурации |
Переменные |
|---|---|---|---|
uid=orgunitsservice_*,cn=sysaccounts,cn=etc,$SUFFIX
|
КД |
/etc/aldpro/core.env
|
ORGUNITS_MOVE_SYSACCOUNT_USER
ORGUNITS_MOVE_SYSACCOUNT_PASSWORD
|
uid=roleservice_*,cn=sysaccounts,cn=etc,$SUFFIX
|
КД |
/etc/aldpro/core.env
|
ROLESERVICE_USERNAME
ROLESERVICE_PASSWORD
|
uid=saltstackservice_*,cn=sysaccounts,cn=etc,$SUFFIX
|
КД |
/etc/aldpro/core.env
|
LDAP_USER
LDAP_PASSWORD
|
uid=trustsservice_*,cn=sysaccounts,cn=etc,$SUFFIX
|
КД |
/etc/aldpro/core.env
|
TRUSTS_SYSACCOUNT_USER
TRUSTS_SYSACCOUNT_PASSWORD
|
uid=syncer/{domain}@{REALM},cn=sysaccounts,cn=etc,$SUFFIX
|
КД |
/etc/aldpro/core.env
|
SYNCER_ALDPRO_LOGIN
SYNCER_ALDPRO_PASSWD
|
Удалить устаревшую УЗ:
ldapdelete -x -D "cn=Directory Manager" -W "uid=<system_account>,cn=sysaccounts,cn=etc,dc=example,dc=ru"
Блокировка системных УЗ для работы с LDAP¶
Блокировка УЗ 389 DS выполняется посредством добавления атрибута nsAccountLock, который обеспечивает блокировку прохождения аутентификации с LDAP-сервером. Для добавления атрибута необходимо выполнить команду:
ldapmodify -x -D "cn=Directory Manager" -W <<EOF
dn: uid=<system_account>,cn=sysaccounts,cn=etc,dc=example,dc=ru
changetype: modify
add: nsAccountLock
nsAccountLock: FALSE
EOF
где:
<system_account>— имя существующей системной учетной записи в деревеcn=sysaccounts;dc=example,dc=ru— доменная компонента.
Добавление атрибута для соответствующей УЗ происходит единожды, далее значение атрибута возможно к изменению согласно предполагаемым сценариям:
для блокировки значение
nsAccountLockустанавливается в TRUE;для разблокировки значение
nsAccountLockустанавливается в FALSE.
Для возможности изменить атрибут необходимо выполнить команду:
ldapmodify -x -D "cn=Directory Manager" -W <<EOF
dn: uid=<system_account>,cn=sysaccounts,cn=etc,dc=example,dc=ru
changetype: modify
replace: nsAccountLock
nsAccountLock: FALSE
EOF
nsAccountLock: <TRUE/FALSE> изменяется согласно указанным ранее сценариям.
После выполнения блокировки УЗ выполнение подключений сервисов, использующих УЗ, станет недоступно. В портале при подобных ограничениях будут получены ошибки, обозначающие невозможность соответствующими сервисами и скриптами выполнять аутентификацию под указанной УЗ.
Управление системными учетными записями PostgreSQL¶
Переопределение системных УЗ для работы с PostgreSQL¶
В процессе обновления учетных данных для системных учетных записей, использующихся в функционировании PostgreSQL, необходимо провести актуализацию непосредственно в СУБД на тех подсистемах, где требуется обновление. Для переопределения необходимо создать системную УЗ на замену:
Системная УЗ |
Подсистема |
База данных |
Создание УЗ для замены |
|---|---|---|---|
async_db_* |
КД |
async |
sudo -u postgres psql -c "CREATE USER <user> WITH PASSWORD 'pass';"
sudo -u postgres psql -d <database> -c "REASSIGN OWNED BY <old_user> TO <new_user>;"
sudo -u postgres psql -d <database> -c "DROP OWNED BY <old_user>;"
|
core_db_* |
КД |
core |
sudo -u postgres psql -c "CREATE USER <user> WITH PASSWORD 'pass';"
sudo -u postgres psql -d <database> -c "REASSIGN OWNED BY <old_user> TO <new_user>;"
sudo -u postgres psql -d <database> -c "DROP OWNED BY <old_user>;"
|
syncer_db_* |
КД |
syncer |
sudo -u postgres psql -c "CREATE USER <user> WITH PASSWORD 'pass';"
sudo -u postgres psql -d <database> -c "REASSIGN OWNED BY <old_user> TO <new_user>;"
sudo -u postgres psql -d <database> -c "DROP OWNED BY <old_user>;"
|
repo_db_* |
Репозитории ПО |
repo |
sudo -u postgres psql -c "CREATE USER <user> WITH PASSWORD 'pass';"
sudo -u postgres psql -d <database> -c "REASSIGN OWNED BY <old_user> TO <new_user>;"
sudo -u postgres psql -d <database> -c "DROP OWNED BY <old_user>;"
|
osinstall_db_* |
Установка ОС по сети |
osinstall |
sudo -u postgres psql -c "CREATE USER <user> WITH PASSWORD 'pass';"
sudo -u postgres psql -d <database> -c "REASSIGN OWNED BY <old_user> TO <new_user>;"
sudo -u postgres psql -d <database> -c "DROP OWNED BY <old_user>;"
|
На данном шаге, при обновлении только пароля существующей системной УЗ, необходимо выполнить команду:
sudo -u postgres psql -d <database> -c "ALTER USER <username> WITH PASSWORD '<new_password>';"
Далее необходимо преобразовать пароль для корректного хранения в файлах конфигурации.
Скачать публичный ключ:
aldpro-salt-call aldpro_subsystems.get_crt_pass_to_fs /tmp/test_cert.crt
где /tmp/test_cert.crt абсолютный путь до ключа.
Преобразовать пароль:
aldpro-salt-call aldpro_subsystems.password_encrypt '<PASSWORD>' public_cert_path=/tmp/test_cert.crt
Актуализировать учетные данные в ключе password записи обновляемой подсистемы DN: fqdn=<fqdn>,cn=computers,cn=accounts,dc=example,dc=ru в атрибуте aldproSubsystemVaultCredentials. Учетные записи PostgreSQL отражены в ключах postgres_<short_system_account_name>. Например, для core_db_* файл конфигурации будет выглядеть следующим образом:
{
"passwords": {
"postgres_core": {
"db_password": "<coreDbEncryptPassword>"
}
}
}
Обновить значения ключа password в /etc/aldpro-salt/stack/encrypted_passwords.yml. Например, для core_db_* файл конфигурации будет выглядеть следующим образом:
postgres_core:
db_password: <coreDbEncryptPassword>
Заменить учетные данные в файлах конфигурации:
Системная УЗ |
Подсистема |
Файл конфигурации |
Переменные |
|---|---|---|---|
async_db_* |
КД |
/etc/aldpro/services.env
|
ASYNC_DB_USER
ASYNC_DB_PASSWORD
|
core_db_* |
КД |
/etc/aldpro/core.env
|
CORE_DB_USER
CORE_DB_PASSWORD
|
syncer_db_* |
КД |
/etc/aldpro/core.env /etc/aldpro/syncer.env
|
SYNCER_DB_USER
SYNCER_DB_PASSWORD
|
repo_db_* |
Репозитории ПО |
/etc/aldpro/repo.env
|
DB_USER
DB_PASSWORD
|
osinstall_db_* |
Установка ОС по сети |
/etc/aldpro/os.env
|
POSTGRES_USER
POSTGRES_PASSWORD
|
Удалить устаревшую УЗ:
sudo -u postgres psql -d <database> -c "DROP ROLE <user>;"
Блокировка системных УЗ для работы с PostgreSQL¶
Блокировка системных УЗ осуществляется средствами PostgreSQL:
Системная УЗ |
Подсистема |
Блокировка |
Разблокировка |
|---|---|---|---|
async |
КД |
NOLOGIN позволяет заблокировать пользователя
|
LOGIN позволяет разблокировать пользователя
|
core |
КД |
NOLOGIN позволяет заблокировать пользователя
|
LOGIN позволяет разблокировать пользователя
|
syncer |
КД |
NOLOGIN позволяет заблокировать пользователя
|
LOGIN позволяет разблокировать пользователя
|
repo |
Репозитории ПО |
NOLOGIN позволяет заблокировать пользователя
|
LOGIN позволяет разблокировать пользователя
|
osinstall |
Установка ОС по сети |
NOLOGIN позволяет заблокировать пользователя
|
LOGIN позволяет разблокировать пользователя
|
Управление системными учетными записями RabbitMQ, используемыми для работы ALD Pro¶
Переопределение системных УЗ для работы с RabbitMQ¶
В процессе обновления учетных данных для системных учетных записей, использующихся в функционировании RabbitMQ, необходимо провести актуализацию непосредственно в системе управления очередями на тех подсистемах, где требуется обновление. Для этого следует воспользоваться следующими командами:
Системная УЗ |
Подсистема |
Создание новой УЗ |
|---|---|---|
async_rabbitmq_* |
КД |
Создать нового пользователя:
Присвоить роль администратора:
Выделить права:
-p значение VHOST из файлов переменных *.env |
core_rabbitmq_* |
КД |
Создать нового пользователя:
Присвоить роль администратора:
Выделить права:
-p значение VHOST из файлов переменных *.env |
repo_rabbitmq_* |
Репозитории ПО |
Создать нового пользователя:
Выделить права:
-p значение VHOST из файлов переменных *.env |
osinstall_rabbitmq_* |
Установка ОС по сети |
Создать нового пользователя:
Присвоить роль администратора:
Выделить права:
-p значение VHOST из файлов переменных *.env |
На данном шаге, при обновлении только пароля существующей системной УЗ, необходимо выполнить команду:
rabbitmqctl change_password <system_account> <newpassword>
Далее необходимо преобразовать пароль для корректного хранения в файлах конфигурации.
Скачать публичный ключ:
aldpro-salt-call aldpro_subsystems.get_crt_pass_to_fs /tmp/test_cert.crt
где /tmp/test_cert.crt абсолютный путь до ключа.
Преобразовать пароль:
aldpro-salt-call aldpro_subsystems.password_encrypt '<PASSWORD>' public_cert_path=/tmp/test_cert.crt
Актуализировать учетные данные в ключе password записи обновляемой подсистемы DN: fqdn=<fqdn>,cn=computers,cn=accounts,dc=example,dc=ru в атрибуте aldproSubsystemVaultCredentials. Учетные записи RabbitMQ отражены в ключах rabbitmq_<short_system_account_name>. Например, для core_rabbitmq_* файл конфигурации будет выглядеть следующим образом:
{
"passwords": {
"rabbitmq_core": {
"db_password": "<coreRabbitmqEncryptPassword>"
}
}
}
Обновить значения ключа password в /etc/aldpro-salt/stack/encrypted_passwords.yml. Например, для core_rabbitmq_* файл конфигурации будет выглядеть следующим образом:
rabbitmq_core:
db_password: <coreRabbitmqEncryptPassword>
Актуализировать учетные данные в файлах конфигурации:
Системная УЗ |
Подсистема |
Файл конфигурации |
Переменные |
|---|---|---|---|
async |
КД |
/etc/aldpro/services.env
|
ASYNC_RABBIT_LOGIN
ASYNC_RABBIT_PASSWORD
|
core |
КД |
/etc/aldpro/core.env
|
CELERY_RABBIT_USER
CELERY_RABBIT_PASSWORD
|
repo |
Репозитории ПО |
/etc/aldpro/repo.env
|
CELERY_RABBIT_USER
CELERY_RABBIT_PASSWORD
|
osinstall |
Установка ОС по сети |
/etc/aldpro/os.env
|
CELERY_RABBIT_USER
CELERY_RABBIT_PASSWORD
|
Удалить устаревшую УЗ:
rabbitmqctl delete_user <system_account>
Блокировка системных УЗ для работы с RabbitMQ¶
Механизм блокировки учетных записей (УЗ) в среде RabbitMQ реализуется посредством встроенных функциональных возможностей самой службы обмена сообщениями. Эта процедура осуществляется путем взаимодействия с командным интерфейсом, доступным в RabbitMQ. Пользовательские учетные записи, созданные внутри системы, обладают определенными правами доступа и полномочиями, определяющими уровень привилегий для выполнения операций в брокере сообщений, при выполнении процедуры блокировки соответствующие разрешения и полномочия учетной записи аннулируются, что фактически лишает пользователя способности взаимодействовать с сервисом, выполняя запланированные действия.
Системная УЗ |
Подсистема |
Блокировка |
Разблокировка |
|---|---|---|---|
async |
КД |
Команда
-p значение VHOST из файлов переменных *.env |
rabbitmqctl set_permissions -p <vhost> <system_account> ".*" ".*" ".*"
|
core |
КД |
Команда
-p значение VHOST из файлов переменных *.env |
rabbitmqctl set_permissions -p <vhost> <system_account> ".*" ".*" ".*"
|
repo |
Репозитории ПО |
Команда
-p значение VHOST из файлов переменных *.env |
rabbitmqctl set_permissions -p <vhost> <system_account> ".*" ".*" ".*"
|
osinstall |
Установка ОС по сети |
Команда
-p значение VHOST из файлов переменных *.env |
rabbitmqctl set_permissions -p <vhost> <system_account> ".*" ".*" ".*"
|
Управление системными учетными записями Zabbix и Grafana¶
Переопределение системных УЗ для работы с Zabbix и Grafana¶
В процессе обновления учетных данных для системных учетных записей, использующихся в функционировании Zabbix и Grafana, необходимо провести актуализацию непосредственно в системе мониторинга на тех подсистемах, где требуется обновление. Для переопределения monitoring_* или zabbix_api_* необходимо создать системную УЗ на замену, воспользовавшись веб-интерфейсом Zabbix:
На данном шаге, при обновлении только пароля существующей системной УЗ, необходимо выполнить команду обновления пароля в карточке пользователя:
Изменение учетных данных УЗ в Grafana осуществляется аналогично через веб-интерфейс:
Обновление или сброс пароля администратора Grafana можно выполнить с помощью команды, которая автоматизирует процесс изменения пароля во всех необходимых конфигурациях:
grafana-cli admin reset-admin-password <new password>
Далее необходимо преобразовать пароль для корректного хранения в файлах конфигурации.
Скачать публичный ключ:
aldpro-salt-call aldpro_subsystems.get_crt_pass_to_fs /tmp/test_cert.crt
где /tmp/test_cert.crt абсолютный путь до ключа.
Преобразовать пароль:
aldpro-salt-call aldpro_subsystems.password_encrypt '<PASSWORD>' public_cert_path=/tmp/test_cert.crt
Актуализировать учетные данные в записи каталога обновляемой подсистемы:
Системная УЗ |
DN |
Атрибут |
Ключ |
|---|---|---|---|
monitoring_* |
fqdn=<fqdn_dc>,cn=computers,cn=accounts,dc=example,dc=ru
|
aldproSubsystem VaultCredentials (пробел удалить)
|
zabbix_monitoring:password: <password>
zabbix_monitoring:username: <username>
|
monitoring_* |
fqdn=<fqdn_mon>,cn=computers,cn=accounts,dc=example,dc=ru
|
rbtaSubsystemConfig
|
monitoring_credentials:<monitoring_dc = username>
monitoring_credentials:<monitoring_dc = username>:password: <password>
monitoring_credentials:<monitoring_dc = username>:username <username>
monitoring_status:<monitoring_dc = username>
|
zabbix_api_* |
fqdn=<fqdn_mon>,cn=computers,cn=accounts,dc=example,dc=ru
|
aldproSubsystem VaultCredentials (пробел удалить)
|
zabbix_api:password: <password>
|
admin (grafana) |
fqdn=<fqdn_mon>,cn=computers,cn=accounts,dc=example,dc=ru
|
aldproSubsystem VaultCredentials (пробел удалить)
|
grafana:password: <password>
|
Например, для monitoring_dc01 конфигурация rbtaSubsystemConfig будет выглядеть следующим образом:
{
"is_master": true,
"monitoring_credentials": {
"new_monitoring_dc01": {
"password": "newMonitoringDc01EncryptPassword",
"username": "new_monitoring_dc01"
}
},
"monitoring_status": {
"new_monitoring_dc01": "True"
},
"timestamp": "timestamp",
"version_ald": "3.2.0"
}
Актуализировать учетные данные в файлах конфигурации:
Системная УЗ |
Подсистема |
Файл конфигурации |
Переменные/Ключ |
|---|---|---|---|
monitoring_* |
КД |
/etc/aldpro/core.env
|
ZABBIX_USERNAME
ZABBIX_PSW
|
monitoring_* |
КД |
/etc/aldpro-salt/stack/encrypted_passwords.yml
|
zabbix_monitoring:password:
zabbix_monitoring:username:
|
zabbix_api_* |
Мониторинг |
/etc/systemd/system/aldpro-zabbix-discovering-systemd.conf
|
ALDPRO_ZABBIX_PASSWORD
|
zabbix_api_* |
Мониторинг |
/etc/aldpro-salt/stack/encrypted_passwords.yml
|
zabbix_api:password:
|
zabbix_api_* |
Мониторинг |
/etc/aldpro-salt/stack/aldpro_install.yml
|
aldpro:subsystems:zab bix:zabbix_api:username: (пробел удалить)
|
Например, для monitoring_dc01 файл конфигурации /etc/aldpro-salt/stack/encrypted_passwords.yml будет выглядеть следующим образом:
zabbix_monitoring:
password: newMonitoringDc01EncryptPassword
simple_bind: true
username: new_monitoring_dc01
zabbix: true
Перезагрузить aldpro-salt-minion:
systemctl restart aldpro-salt-minion.service
Пересобрать конфигурацию pillar:
aldpro-salt-call aldpro_subsystems.build_deploy_pillar -c /srv/aldpro-salt/config/
В случае обновления пароля учетной записи zabbix_api_*, которая необходима для интеграции Grafana с Zabbix, необходимо провести соответствующие изменения в конфигурации Grafana.
Перейти в раздел Connections (Подключения) и выбрать пункт Data Sources (Источники данных). В списке источников данных выбрать конфигурацию, связанную с Zabbix. Полный путь до раздела: Home → Connections → Your → connections → Data sources → Zabbix.
В настройках источника данных найти поле, предназначенное для хранения пароля пользователя Zabbix. Ввести новые учетные данные.
После обновления проверить и подтвердить корректность остальных параметров подключения. Нажать кнопку [Save & Test] (Сохранить и протестировать), чтобы проверить соединение с Zabbix и убедиться в правильности введённых данных.
В Zabbix авторизоваться под новой УЗ и удалить неактуальную:
Блокировка системных УЗ для работы с Zabbix и Grafana¶
Блокировка УЗ Zabbix осуществляется через добавление пользователя в группу Disabled:
Блокировка УЗ в Grafana осуществляется через веб-интерфейс:
Генерация SECRET_KEY¶
В конфигурационных файлах ALD Pro, указанных выше, содержатся переменные SECRET_KEY, представляющие собой ключи для Django, которые автоматически создаются модулями ALD Pro. Если возникает необходимость замены ключа, следует воспользоваться командой:
aldpro-salt-call django_secret_key.generate
В файлах .env также хранится переменная NOTIFICATIONS_BASE64_PASSWORD, необходимая для отображения иконки статуса «Связь установлена» на главной странице портала управления. Для генерации NOTIFICATIONS_BASE64_PASSWORD используется команда:
aldpro-salt-call hashutil.base64_encodestring $(openssl rand -hex 28)
Новый пароль указывается в файлах /etc/aldpro/services.env и /etc/aldpro/core.env. Генерация производится на каждом КД.
В конфигурационных файлах ALD Pro на подсистемах (/etc/aldpro/repo.env и /etc/aldpro/os.env) также содержатся переменные SECRET_KEY, представляющие собой ключи для Django, которые автоматически создаются модулями ALD Pro. Если возникает необходимость замены ключа, следует воспользоваться командой:
aldpro-salt-call django_secret_key.generate
Перезапуск затронутых сервисов ALD Pro и других приложений после смены учетных данных¶
После изменения пароля и обновления конфигураций приложений необходимо перезапустить:
FreeIPA (IPA сервисы);
389 DS (служба LDAP);
службы репликации;
сервисы, использующие Kerberos или Sudo;
другие связанные сервисы и приложения.
На каждом контроллере домена выполнить:
aldproctl restart
Для перезапуска репликации необходимо временно отключить соглашение о репликации:
dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt disable --suffix "dc=example,dc=com" example-agreement
Где example-agreement — наименование соглашения о репликации. Для получения необходимо выполнить команду:
dsconf -j <INSTANCE> replication status --suffix dc=example,dc=com
agmt-name будет соответствовать example-agreement. Повторно включить соглашение о репликации, чтобы установить обновление:
dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt enable --suffix "dc=example,dc=com" example-agreement
Проверить статус репликации:
dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt status --suffix "dc=example,dc=com" example-agreement
Дополнительно:
systemctl restart postgresql sssd apache2 rabbitmq-server
На сервере установки ОС:
systemctl restart tftpd-hpa rabbitmq-server postgresql
На сервере репозиториев:
systemctl restart rabbitmq-server postgresql
На сервере мониторинга:
systemctl restart zabbix-server.service grafana-server.service postgresql apache2
После смены пароля и перезапуска репликации убедиться, что синхронизация данных между репликами работает корректно. Например, создать произвольную запись (нового пользователя) на одном сервере и проверить, что эта же запись появилась на других репликах.
Также рекомендуется произвести перезапуск сторонних служб, не являющихся частью ALD Pro, которые задействовали системные учетные записи.